(1) Field of the Invention
The present invention relates to transmission rate monitoring apparatus and method, and more particularly, to transmission rate monitoring apparatus and method for monitoring the transmission rate of a transmission channel.
(2) Description of the Related Art
With the popularization of the Internet, communications using variable-length data such as IP (Internet Protocol) packets have become more and more prevalent.
As a conventional form of providing Internet service, best-effort delivery type was popular wherein no guarantee is given with respect to delay of data, transmission rate and the like. With the recent advent of new services such as VoIP (Voice over IP), VPN (Virtual Private Network), etc., however, there has been a demand for guaranteeing QoS (Quality of Service) on an END-to-END basis.
Transmission rate (transmission band) is one such QoS. The transmission rate indicates an amount of data that each user can transmit within a predetermined time. If no guarantee is given for the transmission rate, certain user's communication at a rate exceeding the declared transmission rate overrides other users' transmission rates, causing lowering of the communication quality, network congestion, etc.
In order to guarantee the transmission rate, it is necessary that the transmission rate (band in use) currently used by each user should be monitored. There have conventionally been known a token bucket procedure and a leaky bucket procedure as principal methods for monitoring the transmission rate.
FIG. 11 illustrates a transmission rate monitoring method according to the token bucket procedure.
According to the token bucket procedure, a bucket 1 with a bucket size B is presumed into which tokens (water) flow at a fixed rate. If the packet size L of a received packet 2 or 3 is greater than the amount of tokens contained in the bucket 1 (value of a token bucket counter TBC), the packet is discarded as being not acceptable. Thus, on the average, the transmission rate of data flowing through the network is controlled so as not to exceed a rate R of tokens poured into the bucket.
FIG. 12 illustrates the control according to the token bucket procedure. In the figure, the horizontal axis indicates time t and the vertical axis indicates the value of the token bucket counter TBC. The broken line parallel with the horizontal axis represents the bucket size B.
First, at time t1, a packet with a packet size L1 is received, whereupon the packet size L1 is compared with the value of the token bucket counter TBC. Since the value of the token bucket counter TBC is greater than the packet size, the packet is judged acceptable and sent out onto the network. At this time, a value corresponding to the packet size L1 is subtracted from the token bucket counter TBC. The value of the TBC increases thereafter at the token rate R.
Subsequently, at time t2, a packet with a packet size L2 is received, whereupon a determination is made in the same manner as stated above. This packet also is judged acceptable and sent out onto the network. A similar operation is repeated thereafter at time t3 and time t4.
A packet arriving at time t5 has a packet size L5 greater than the then-counted value of the token bucket counter TBC. Accordingly, the packet is judged unacceptable and is discarded.
The process described above makes it possible to control the transmission rate of specific packets flowing through the network.
FIG. 13 illustrates a transmission rate monitoring method according to the leaky bucket procedure.
In the leaky bucket procedure, a bucket 10 with a bucket size B is presumed from which tokens (water) flow out at a fixed rate. If the sum of the packet size L of a received packet 11 or 12 and the amount of tokens contained in the bucket 10 (value of a leaky bucket counter LBC) is greater than the bucket size B, the packet is judged unacceptable and discarded. If the former is not greater than the latter, the packet concerned is judged acceptable and sent out onto the network, and also a value corresponding to the packet size is added to the leaky bucket counter LBC. Thus, on the average, the transmission rate of data flowing through the network is controlled so as not to exceed a rate R of tokens flowing out of the bucket.
FIG. 14 illustrates the control according to the leaky bucket procedure. In the figure, the horizontal axis indicates time t and the vertical axis indicates the value of the leaky bucket counter LBC. The broken line parallel with the horizontal axis represents the bucket size B.
First, at time t1, a packet with a packet size L1 is received, whereupon the sum of the packet size L1 and the value of the leaky bucket counter LBC is compared with the bucket size B. Since the latter is greater than the former, the packet is judged acceptable and sent out onto the network. At this time, a value corresponding to the packet size L1 is added to the leaky bucket counter LBC. The value of the LBC decreases thereafter at the token rate R.
Subsequently, at time t2, a packet with a packet size L2 is received, whereupon a determination is made in the same manner as mentioned above. This packet also is judged acceptable and sent out onto the network. A similar operation is repeated thereafter at time t3 and time t4.
The sum of the packet size L5 of a packet arriving at time t5 and the then-counted value of the leaky bucket counter LBC is greater than the bucket size B. Accordingly, this packet is judged unacceptable and is discarded.
The process described above makes it possible to control the transmission rate of specific packets flowing through the network.
In the case of carrying out either the token bucket procedure or the leaky bucket procedure, tokens that have flown into (or out of) the bucket need to be calculated using the time t1 of reception of the immediately preceding packet, the current time t2 and the token rate R, and generally the expression (t2−t1)×R is used for the calculation.
Since the expression involves multiplication, a problem arises in that the configuration of the apparatus is complicated and that a longer time is required for the calculation.
Also, the length of time that can be spent on the calculation is nearly proportional to the packet length. Consequently, if the packet length is short, only a short period of time can be spent on the calculation, and in the worst case the calculation cannot be completed within the required time.